エンジニアのためのマネジメントキャリアパス ― テックリードから CTO までマネジメントスキル向上ガイド

https://images-na.ssl-images-amazon.com/images/I/51sEua-%2BejL._SX350_BO1,204,203,200_.jpg

O'Reilly Japan : https://www.oreilly.co.jp/books/9784873118482/

自分自身がエンジニアリングマネジャーになってまだ 1 年経過していなくて手探り状態という状況だったり、今の部署でエンジニアのキャリアパスをどう定義するかという話をしていたりする中で、非常に参考になる本だった。

「チームの組み方として職能横断のプロダクト志向なチームと技術志向なチームの 2 通りがあって、どういう組織体制にするのがいいのだろうか」、「プロダクトマネジャーとエンジニアリングマネジャーとの関係はどういう形がいいのか」みたいなことを最近考えていたので、そういった点でも気づきを得られたので良かった。

1 章マネジメントの基本

上司に求めるべきもの

一対一のミーティング (1 on 1)

人間的なつながりを作る

要検討事項について上司と話し合う定期的な場

フィードバックの提供

トレーニングとキャリアアップ

マネジメントのされ方

自分が何を望んでいるのかじっくり考える

自分に対する責任は自分で負う。望みをかなえるための努力を惜しまない

不安や不満が解消できないことが続くなら声をあげるとか、昇給を望むならその意思表示をするとか、昇進を望むならそのために何が必要か探るとか

上司も人の子

nobuoka.icon わかる〜〜〜

上司を賢く選ぶ

nobuoka.icon これ大学生の時に研究室の師に言われたな。「師を選ぶ能力も大事だ」って

2 章メンタリング

「メンター」について

メンターにとっては他者への責任を負う経験をする好機

メンティーにとっては専任のお目付け役に教えを請う好機

インターンのメンタリングにおけるスキル

傾聴

明確な伝達

なすべきこと、出すべき結果を明確に伝える

自身の対応の調整

インターンの反応を見定めて適切に対応するための調整能力

新入社員のメンタリング

メンターが新入社員の新鮮な目を通して社内を見直すきっかけになる

不文律 (明文化されていないルール) とか、ドキュメントが古くなっているとか

新人を他の社員に紹介するのは人脈を広げる良い機会 (メンターにとっても新人にとっても)

人脈、ネットワークこそがあらゆるキャリアの基盤となる

技術やキャリアに関するメンタリング

シニアエンジニアがチームの若手を育成するためにメンタリングする、など

多くは非公式な制度だが、制度化している会社もある

別チームの人同士でメンター・メンティー関係を作るなど

制度化は人脈作りに資することもあるが、漠然とした義務感を抱かせる場合もある

種々のメンタリング関係においては、「その関係に対する期待や目標を明確にすること」が大事

メンターを管理するコツ

改善の源は計測 : 焦点を絞った計測可能で明確なゴールを設定すること

3 章テックリード

テックリード (tech lead) の話

プロジェクトマネジメントの話

キャリアの梯子を登るにつれて、自分ひとりでこなせる範囲を超えた複雑な仕事を分割するコツを身に付ける必要

アジャイル開発が広まっているが、アジャイル開発でもプロジェクトマネジメントは必要だし、アジャイル開発できないプロジェクトもある

いずれにせよプロジェクトマネジメントは必須で、それを担うのがテックリード

プロジェクトの計画づくりの真価は、実際にプロジェクトを動かしていくよりも前にプロジェクトをある程度掘り下げて考える部分にある

完璧な計画を立てることでも、詳細を漏れなく把握することでも、将来を予測することでもない

実務 : 複数の工程に分割 → プロジェクトを始動し、調整を加えながら進行 → TBD

4 章人の管理

管理者になりたての適応期に重点的に取り組む課題 : 自分なりの管理スタイルを見つけること

主な仕事 4 点

直属の部下との関係構築

相手を理解するため (特にマネジメントしやすくするため) の質問をする

Lara Hogan の「Questions for our first 1:1」の内容も

今後 1 ヵ月、2 ヵ月、3 ヵ月の計画を立てさせる

新人研修用のドキュメントを更新させて、チームに対する理解を促進

自分の流儀や要望を明確に伝える

新人からもフィードバックを得る (3 ヵ月経過後が良い)

定期的な 1 対 1 のミーティング (以下 1-1)

キャリアアップや作業の進捗状況、改善領域、功績の報奨などに関するフィードバック

各メンバーの研鑽を要する領域の見極めと、その領域の能力強化

5 章チームの管理

チーム全体の責任を負う管理者

著者は、このランクの職位を「エンジニアリングリード」 (engineering lead) と呼ぶ

チームの管理者として人的管理以外に焦点を当てるべき側面を説明

IT スキルの維持 : コードを書く仕事から卒業したとしても、技術面の意思決定を主導する責任を負っている

なぜ小規模な成果物でもコード作成に携わることにこだわるのか？ → ボトルネックや作業工程の問題のありかを素早く察知するために必要

機能不全に陥ったチームへのデバッグ

デリバリにこぎつけられない : 催促すべきときと口出しを控えるべきときのバランスを見極める

厄介な部下 : ブリリアントジャークほどでなければ、問題の言動を見せたらすぐに注意する

チームの意思決定を主導するコツ

データ重視の文化を根付かせる

顧客に対する共感を深める

将来を見据える

チームの意思決定やプロジェクトの結果を振り返る

プロセスと日程を振り返る

より専門的なプロジェクト管理

TBD

6 章複数チームの管理

筆者の前職 Rent the Runway では、エンジニアが複数の大きなチームの管理を初体験する職位は大抵技術部長 (director of engineering)

TBD

7 章複数の管理者の管理

複数の管理者を率いる管理者が会社から期待される職務内容は、複数のチームを率いる管理者の場合と大きくは変わらない

責任の重さが違う

複数の管理者を率いる場合の方が、各チームの専門分野が広がり、プロジェクトの数も部下の数も自分ひとりでは到底できない

間接的な管理となるため、詳細をつかみづらく、実態がわかりづらい

これまでは各チームの開発者全員と個々に顔を合わせていても、このレベルになると難しい

これまでの延長ではなく、はるかにスケールの大きなゲームの第 1 段階と捉えるべき

最終的には最高幹部や上級経営者に至る道の入口

コツ

2 ランク以上離れた部下を管理するコツ : スキップレベルミーティング

直属の管理者たちに責任を課すコツ :

TBD

8 章経営幹部

CTO や技術担当バイスプレジデント、技術本部長、技術部門の統括者などの様々な呼称がある

経営幹部の第一の仕事はリーダーを務めること

『HIGH OUTPUT MANAGEMENT』では、経営幹部の職務を 4 つに大別

情報の収集・共有

注意喚起

意思決定

ロールモデル

参考図書

コーチングの神様が教える「できる人」の法則

HIGH OUTPUT MANAGEMENT

米海軍で屈指の潜水艦艦長による「最強組織」の作り方

9 章文化の構築

10 章まとめ

#書籍 #文献